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REMARKS 
Status Summary 

Claims 1-43 are pending in the present application, of which claims 1,16, and 31 
are presented in independent form. Claims 1-8, 10-23, 25-37, and 39-43 stand 
rejected. Claims 1-4, 7-9, 11-13, 15-19, 22-24, 26-28 30-34, 36-41, and 43, would be 
amended upon entry of this Amendment. Claims 5, 6, 20, 21, and 35 would be 
cancelled upon entry of this Amendment. Applicants respectfully request that the 
amendments be entered after final because they do not raise new issues, but instead 
incorporate subject matter into the independent claims that the Examiner has previously 
searched. 

Claim Objection(s) 

Although not expressly stated in the text of the Office Action, the Office Action 
Summary indicates that the Examiner has maintained the objection to claims 9, 24, and 
38 for being dependant on a rejected claim along with the indication of allowability 
should any claim be rewritten in independent form. 

Further, claim 1 7 would be amended merely to address an informality. Thus, this 
amendment would be made for reasons unrelated to the statutory requirements for a 
patent and have not narrowed the scope of the claim. Accordingly, the amendment of 
this claim would not raise any presumptions regarding, nor trigger the application of the 
doctrine of prosecution history estoppel to limit the range of equivalents. 

In particular, claim 17 would be amended to properly refer to the computer 
readable medium of claim 16 rather than the method of claim 16. 

Claim Rejectionfs) - 35 U.S.C. § 103(a) 
Claims 1-5, 7-8, 10-14, 16-20, 22-23, 25-29, 31-34, 36-37, and 39-42 stand 
rejected as being unpatentable over U.S. Patent No. 6,721,747 to Lipkin (hereinafter 
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"Lipkin"), in view of U.S. Patent No. 6,629, 104B1 to Parulski, et al. (hereinafter 
"Parulski"). 

Claim 1, as amended, would more clearly recite the defined custom metadata 

schema. Specifically, claim 1 would be amended to recite: 

providing form information to a client computer for presenting a form- 
driven user interface that allows the user to specify, without using syntax 
required by an underlying specification language, a plurality of properties, 
including constraints supported by the underlying specification language, 
to thereby define a custom metadata schema; and 
storing the custom metadata schema in the metadata library. 

In the instant application, vocabulary is used interchangeably with the term schema 
(see, for example, page 8 lines 13-16 of the application). The custom vocabulary or 
schema includes properties that include constraints. Amended claim 1 would make 
clear that the plurality of properties allowed to be specified by the user to create the 
custom metadata schema include more than just the addition of metadata tags and their 
associated values. Rather, the specified properties create a custom metadata schema 
that is a new schema that includes new constraints. Claim 1 now clearly defines the 
custom metadata schema to include constraints provided by the user. 

Amended claim 1 includes providing form information to a client computer for 
presenting a form-driven user interface that allows the user to specify constraints 
supported by the underlying specification language without using syntax required by an 
underlying specification language.. In the rejection of canceled claim 6, the Examiner 
contends that the cited art discloses a form driven interface for entering property names 
and constraint values. Applicants respectfully disagree. 

Initially, Applicants would like to point out an apparent typographical error in the 

Action. Item 6 on page 8 of the Action recites: 

Claims 6,21 and 35 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lipkin (U.S. Patent 6,721,74782) in view of Parulski et al. ('parulski") US 
Patent no.6629104B1 as applied to claims 1-5,7-8, 10-14, 16-20,22-23,25-29,31- 
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34,36- 37,39-42 and further in view of Halstead et al. ("Halstead") U.S. Patent 
6,502,102. 

In particular, the Action cites col. 6, lines 18-26 and figures 4 and 5 of Halstead. 
The cited section of Halstead, however, is not relevant here. The Action also refers to a 
patent to Haswell later in that same section. U.S. Patent 6,363,392 to Haswell was 
cited in an earlier Action. The above referenced section (col. 6, lines 18-26 and figures 
4 and 5) of Haswell is related to the entry of property values. As the Halstead patent 
bears no relation to claim 6, and the Haswell patent was referenced previously, 
applicants proceed under the assumption that Haswell was the intended reference 
rather than Halstead. 

The cited section of Haswell recites: 

FIG. 4 shows a template that might be returned by processing logic in 
response to a request to add a record manually to the personal database. 
In this case, an address book type personal database was selected. The 
user may select the customize option to add additional fields or to rename 
or reorder the fields. FIG. 5 shows a template returned in response to 
customize command. 

This section allows the user to add new fields, rename fields and reorder the fields. 
Haswell does not, in this section or any other, teach the ability of a user to specify 
constraints as recited in claim 1 . Haswell relates to a user interface that allows a user 
to create new fields for use in an online address book and then arrange those fields. 
Haswell does not teach a user interface that allows a user to enter constraints so as to 
define a custom metadata schema. Accordingly, since the cited documents fail to 
disclose or suggest all of the claim limitations for at least the above reasons, applicants 
assert that claim 1 as amended, would define over the prior art. 

Further, Haswell is directed to a "method and system for providing a flexible, 
web-sharable database with proximity searching capability." Haswell does not discuss 
metadata schemas at any point. Haswell is not related to metadata schemas. Rather it 
is directed to a web-shareable database. Applicants respectfully assert that, knowing 
Parulski and Lipkin, one of ordinary skill in the art would have had no motivation to look 
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to Haswell for any purpose. Thus, applicants assert the combination of references is 
improper in rejecting claim 6, and would be equally improper to reject claim 1 as 
amended. 

Moreover, the form-driven user interface of claim 1 further allows the user to 

specify constraints without using syntax required by an underlying specification 

language. That is, users can define custom metadata schemas without any knowledge 

of the underlying schema language. A schema language such as RDF is complex, and 

as stated in the application (page 3 lines 8-20): 

One problem with RDF, however, is that the syntax is complicated to 
learn, especially for a non-computer user. For instance, the following is a 
portion of the RDF syntax for describing a report: 
description about = "http://flashpoint,com./report.htmr > 

<DC:Title> Specifying and Assigning Metadata </DC:Title> 

<DC:Creator> Paul Morris </DC:Creator> 

<DC:Date> 2001-01-01 </DC:Date> 

<OC:Subject> Metadata, RDF </DC:Subject> 
</De$cription> 
</RDF> 

Thus, users will not be able to specify metadata to suit his/her own 
particular needs without becoming an expert in RDF and XML. 

In particular, claim 1 as amended recites a "user interface that allows the user to 
specify, without using syntax required by an underlying specification 
language,... constraints supported by the underlying specification language." None of 
the prior art, alone or in combination teach the above stated recitation. Haswell, which 
is cited as teaching the form-driven interface, is not related to metadata schemas at all 
and thus cannot anticipate the claim. The other references likewise fail to teach a user 
interface that allows a user to specify constraints without using syntax required by an 
underlying specification language. Accordingly, since the cited documents fail to 
disclose or suggest all of the claim limitations for at least the above reasons, applicants 
assert that claim 1 as amended, would define over the prior art. 

Furthermore, none of the cited documents, alone or in combination, disclose or 
suggest defining a custom metadata schema (e.g., a custom metadata vocabulary) that 
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includes user specified constraints, as defined in claim 1 . The Examiner admits that 

Lipkin does not explicitly teach "metadata vocabularies." The Examiner cites Parulski 

as disclosing metadata vocabularies. Applicants respectfully disagree. The sections of 

Parulski cited by the Examiner read as follows: 

Operation 110 discloses prompting a user to create "labels" for their 
pictures (i.e., images), prior to capturing any images, for the purpose of 
locating (i.e., retrieving) the pictures at a later time. 
Operation 150 causes user labels to be stored in a metadata database. 
This completes the process of developing the database of pre-assigned 
metadata labels personalized for the particular user. Some time later (e.g., 
immediately thereafter, or several hours later, or several days later), a 
user can capture one or several images and transfer the captured images 
to the computer in operation 160. 

Operation 1 75 queries the user whether more labels should be added to 
the images. Simultaneously, operation 200 adds a selected label to 
metadata for all selected images. Operation 180 receives an affirmative 
response from the query of operation 175. The user selects one, many, or 
all of the images from the thumbnail display in operation 180. A final query 
operation 185 asks whether the label is part of a pull down menu. An 
affirmative response is an input for operation 190, wherein the user 
selects a label by clicking on a menu item. Next, operation 200 adds the 
selected label to metadata for all selected images. A negative response 
the final query operation 185 causes operation 195 to prompt the user to 
enter in a label, which is then added to the metadata database. 

Applicants respectfully submit the above language discloses adding new 
metadata labels to selected images. Further those new labels can then be added to a 
metadata database. The new labels and the values stored in those new labels form a 
key pair. The metadata database disclosed by Parulski includes only those key pairs 
(the metadata labels and the values stored therein). Nowhere in Parulski is any 
additional data stored in the metadata database. Accordingly, Parulski does not 
disclose or suggest specifying constraints for the metadata database. As such, Parulski 
does not disclose allowing a user to specify constraints supported by the underlying 
specification language, as defined in claim 1 of the instant application. 
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User-specified constraints are described throughout the specification of the 

instant application. For example, as described in the specification: 

Each schema or vocabulary 84 specifies the metadata properties in that 
vocabulary and specifies constraints that must be enforced in order to comply 
with the vocabulary. The present invention allows users 18 and groups to define 
their own schemas, which may include the universal schema and may borrow 
from other vocabularies 84. (Page 8, lines 1 3-1 7). 

For example, the homepage for the photosharing site 12 may display a web page 
having the following links; "Create A New Metadata Vocabulary" and "Search For 
A Metadata Vocabulary." If the user clicks on the link to "Create New Metadata 
Vocabulary", then one or more web pages may be displayed with a field for 
entering the title of the new metadata vocabulary, multiple fields for entering 
properties for the vocabulary, and fields for entering constraints on the values for 
each property. (Page 9, lines 1-7). 

A possible constraint is that the country must be chosen from a list specified in 
the vocabulary schema, and the state must be chosen from a list which depends 
on the value of the country. (Page 9, lines 14-16). 

Depending on the type, the Web application 50 may prompt the user 18 to 
provide additional constraints, such as the list of possible values for a list type or 
a range for a numeric range. (Page 13, lines 20-23). 

As can be appreciated by one of ordinary skill in the art, and as is described in 
the specification, constraints can include properties associated with metadata tags and 
values, such as defining relationships between tags and other tags, structure for the 
tags, allowable orders for the tags and/or values, allowable types of tags and/or values, 
allowable ranges of values, and allowable counts of tags and/or values. In each case, 
specifying constraints goes beyond specifying only a tag and value, which is what is 
disclosed in Parulski. 

Moreover, as can be appreciated by one of ordinary skill in this art, adding key 
pairs to an existing metadata database would be done so using the existing schema for 
the database without a need to change the constraints specified by the schema of the 
database. That is, the metadata database disclosed in Parulski operates under a single 
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schema regardless of how many key pairs are added to the database, with new key 
pairs being added to a metadata vocabulary under this single schema. As previously 
stated, the W3C standard supports an infinite number of key pairs 
{name, content) with no change to the schema (see http://www.w3.org/TR/REC- 
html40/struct/global.html#edef-META). As such, a new schema is not created when 
additional key pairs are added to the metadata database in Parulski. 

Since Parulski operates under a single schema, it does not disclose the ability to 
add constraints to create a custom metadata schema. To do so, Parulski would need to 
establish a new schema to support those constraints. Parulski does not disclose the 
creation of a new schema because, as stated above, Parulski operates under a single 
schema to add new labels to a metadata database. There is no need for a new schema 
in the system disclosed by Parulski. Thus, neither Lipkin nor Parulski disclose or 
suggest a custom metadata schema that includes user specified constraints. 

Lipkin is said to anticipate constraints on the values the properties may have in 

Examiner's rejection of claims 5 and 31. When rejecting claim 5, Lipkin is cited, 

specifically the section found at col. 6, lines 16-1 9. The cited section reads as follows: 

DataDictionaryManager-Manage metadata about business objects. This 
metadata is used to generate user interfaces, specify constraints, and 
define object behavior. 

This section is cited as anticipating "allowing the user to specify constraints on 
the values the properties may have." Applicants respectfully disagree. The section 
states that the DataDictionaryManager manages metadata about business objects. The 
metadata about business objects is used to specify constraints. At no point does this 
section, nor any other section in the patent, disclose the ability for the user to specify 
constraints on the values that the properties may have. 

When rejecting claim 31, the Office Action cites Lipkin at col. 12 lines 32-45 and 
col. 1 1 7 lines 54-62 as anticipating a plurality of properties and constraints on values 
the properties may have. The cited sections read as follows: 
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A unique feature of the persistence framework is its support for an 
arbitrary amount of custom information, stored in what is known as 
"custom fields." Experience has shown that predefined business objects 
typically do not express the full set of data a given customer may wish to 
track, and that this data varies from customer to customer. Custom fields 
provide a way for different customers to uniquely extend the data stored 
with a class of business objects. In the current implementation, customers 
are provided with a set of five "custom fields" that can be searched, and 
an unlimited number of "extended custom fields" that cannot be searched, 
but provide additional data validation for date and numeric values. Again, 
the code to save and restore custom fields is all driven off metadata. 

In an embodiment, the invention employs the Resource Description 
Format (RDF), the World Wide Web Consortium's standard for web 
metadata. It meets the above requirements because it is designed to 
support a wide range of different applications, expressing them all in a 
consistent attribute property/value format. The format also allows the 
definition of standard vocabularies for specific application domains, and 
the mixing and matching of these vocabularies to describe a resource. 

Applicants respectfully assert that these sections not only fail to disclose 
constraints on values the property may have, but rather teach away from allowing a 
user to specify constraints. The section from col, 117 states, "meets the above 
requirements because it is designed to support a wide range of different applications, 
expressing them all in a consistent attribute property/value format". In order to maintain 
a consistent attribute property/value format, the user must not be allowed to enter 
constraints. Any constraints entered by a user could change the existing attribute 
property/value format and render the system taught by Lipkin inoperable. 

Accordingly, since the cited documents fail to disclose or suggest all of the claim 
limitations for at least the above reasons, the obviousness rejection of claim 1 should be 
withdrawn. Further, independent claims 16 and 31 include analogous distinguishing 
features and are novel and inventive for at least the same reasons. Furthermore, 
dependent claims 2-4, 7-8, 10-15, 17-19, 22-23, 25-30, 32-34, 36-43 are novel and 
inventive for at least the same reasons. 
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Applicants have taken care not to raise new issues in the above amendments 
and remarks. Applicants believe the amendments would place the case in condition for 
allowance. Accordingly, Applicants respectfully request that the Examiner enter this 
Amendment, at least for the limited purpose of Appeal. 

CONCLUSION 

Applicants thank Examiner for Examiner's time in granting an interview to discuss 
the instant application. Applicants further thank Examiner for his assistance in drafting 
the amendments to the claims presented herein. Applicants respectfully assert the 
claims now define over the prior art for at least those reasons stated above. 

In view of the above, it is respectfully submitted that the present application is 
now in proper condition for allowance, and an early notice to such effect is earnestly 
solicited. Entry and favorable consideration of the above amendments and remarks is 
respectfully requested. The Examiner is respectfully requested to telephone the 
undersigned patent attorney at the below-listed number if, after reviewing the above 
Remarks, the Examiner believes outstanding matters remain that may be resolved 
without the issuance of a subsequent Official Action. 
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DEPOSIT ACCOUNT 
The Commissioner is hereby authorized to charge any fees associated with the 
filing of this paper to Deposit Account No. 50-3512 (IPAC, LLC) . 
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